Improve logs when recovering from an interrupted installation#4725
Improve logs when recovering from an interrupted installation#4725FranciscoTGouveia wants to merge 1 commit intorust-lang:mainfrom
Conversation
FranciscoTGouveia
changed the title
| for component in update.components_to_uninstall { | ||
| // If there are no components installed, we don't need to keep | ||
| // checking, we can simply exit the loop earlier. | ||
| if self.installation.list()?.is_empty() { |
There was a problem hiding this comment.
I think in principle this fix is correct, thanks!
However, isn't .list() doing a FS read every time in this loop? I'd imagine the result of .installation.list() to be perfectly predictable (don't care about ToC/ToU for now), so may I ask what do we have in .components_to_uninstall and .installation.list() here?
In other words, could these be two sets of elements of the same format, so that we can make a difference?
There was a problem hiding this comment.
Yes, indeed, .list() implies a FS read, so a reasonable solution may be to enter the loop only if .list() is not empty (i.e., by adding a conditional check before the loop).
so may I ask what do we have in
.components_to_uninstalland.installation.list()here?
In this case, as the toolchain was not installed, .components_to_uninstall was set to all the 6 components (see here), and .installation.list() was empty.
That said, I think a better approach would be to restrict the components_to_uninstall vector to only include components that actually exist; this comment may be misleading in that regard.
This would eliminate the need for the additional check and further simplify the uninstall_component function.
What do you think about this approach?
There was a problem hiding this comment.
Rethinking about it I found out that I might need to be more careful about the aforementioned approach. Could this loop be written this way to defend against the interrupted in-flight state where the component is partially in-place but not appended to the final list yet?
If that is the case, maybe those checks are not to be skipped since otherwise the installation later on will fail (due to the previous version not being uninstalled)... and we should simply downgrade those warning messages to a lower logging level (say debug) and concatenating the info messages? 🤔
2 participants
Related to #4724.
Currently, when a toolchain installation is retried after being interrupted, an excessive number of warnings are emitted.
This patch detects that situation, skips the redundant warnings, and prints a single, more informative message instead.
I would appreciate any feedback on the wording of the new message.
For reference, I leave below the before and after:
Before:
After: